작성하신 코드 내용과 스크럼 보드를 같이 확인했습니다!
집중해서 코드 리뷰 받고 싶으신 부분들을 여기 같이 작성하도록 하겠습니다.

• 컴포넌트를 재활용에 관하여

  • 전달하는 props가 꼬이는 것은 props로 값을 전달하기 전 어떤 것을 전달하면 좋을 지에 대해서, 아직 구현하는 경험이 부족해서인 것 같습니다. React로 기능을 구현할 경우, 가능한 경우에 컴포넌트를 한 번만 정의하고 여러 곳에서 재사용하는 것이 좋습니다. (예를 들어 게시판 같은 사이트에서 안의 내용물만 다르고 기본 골자는 똑같은 프레임을 여러 개 사용한다면, 그 프레임을 담당하는 컴포넌트를 하나만 만들어 상위 컴포넌트에서 props로 내려 내용물을 달리 보이게끔 하는 방식입니다.) 이렇게 하면 중복 코드도 줄일 수 있고, 프레임을 담당하는 컴포넌트 하나만 수정하면 되기 때문에 유지 보수도 쉬워져요. 또한 의존성 부분에서도 하위 컴포넌트는 props로만 값을 받아서 보여주기 때문에 부모 컴포넌트에서 저 자식 컴포넌트가 없어진다 해도 크게 문제가 되지 않습니다. 답변이 되었길 바랍니다!

• 작성한 주석 관련하여

  • 현재 주석은 어느 정도 잘 작성이 되어 있는 걸로 확인이 됩니다. 대신, BookmarkListPage 컴포넌트의 index 혹은 filter가 변경되면 화면에 렌더링되는 아이템이 변화되는 부분을 담당하는 useEffect의 경우 좀 더 설명이 필요한 부분들이 몇 군데 보입니다. 예를 들어
  • const data = all_bookmark.filter((item, idx) => (index - 8 <= idx && idx < index)); 같은 부분은 변수 명만 봐서는 정확히 어떤 데이터를 filter 하는 것인지 모르기 때문에 해당 부분에는 주석으로 설명이 좀 더 붙어 있어야 나중에 확인하셨을 때 한 번에 확인이 가능하실 거예요. 저라면 //모든 북마크 중 현재 index 범위에 해당하는 아이템들을 가져온다. 정도로 남길 것 같습니다. 주석으로 설명을 다는 것도 중요하지만 변수 명과 함수 명을 더 직관적으로 작성하시는 것도 좋을 것 같습니다. 이어 이어지는 filtered 라는 변수 명도 뭘 필터한 건지 변수 명만 봐서는 정확히 알 수 없으니까요...! 주석 + 직관적인 변수, 함수 명이 이후 유지 보수하는 데에 굉장히 많이 도움이 됩니다!

• styled-components 관리 방법

  • 컴포넌트 내부에 styled-components 코드가 너무 길어지면 영학님이 말씀하신 것처럼 확실히 가독성을 저해하는 요소가 되기도 합니다. 그래서 보통 그렇게 길어지게 되면 질문하신 것과 마찬가지로 스타일만 담당하는 컴포넌트로 따로 분리해 import 해와 사용합니다.
  • 이 외 컴포넌트로 분리하지 않고 동일 로직을 복사해서 붙여넣는 식으로 사용하게 되는 것도 가독성 저해 요소로 작용합니다.

• [추가 질문] README 작성하는 방법

  • 이거는 45기 수강생 중에 잘하신 분의 README.md를 보면 좀 감이 오실 것 같아요! 이 분의 README.md가 정말 잘 작성된 예시 중 하나라고 생각이 듭니다. 보시고 영학님도 나름대로 README.md로 솔로 프로젝트에 대해 설명을 하시면 좋을 것 같습니다.

이어 스크럼 보드도 관리를 잘하고 계시는 것 같아 5일 동안 애자일하게 프로젝트를 관리하신 것 같아요. 👏 솔로 프로젝트 마무리 잘 하셔서 포트폴리오 중 하나로 사용하실 수 있길 바랄게요! (혹시 회고를 아직 안 하셨다면 꼭 회고도 진행해보시면 좋겠습니다)

5일 간의 솔로 프로젝트 기간 동안 기능 구현하시느라 고생 많으셨습니다!

@Jeong-hae-rim

꼼꼼한 리뷰 감사합니다 강사님!

관련해서 추가적으로 궁금한 점이 있는데
보통 본격적인 개발 (코드 작성) 에 들어가기 전에 기획은 어느정도로 하는 편인가요?

프로그램을 만들어본 경험이 간단한 Todo 앱 정도가�전부여서
아직 사전 기획 부분이 미숙한 편이라
이번에도 대략적인 그림만 구상하고 코드 작성에 들어갔는데

프로그램을 만들다보니 예상치 못한 변수도 많이 생기고 해서
중간에 불필요한 시간 낭비를 생각보다 많이 했던 것 같습니다ㅠㅠ

개인적으로 든 생각은
유저 플로우를 직접 손으로 그려보고 데이터가 어떻게 전달 되는지까지
세세하게 다 기획한 뒤에 코드를 작성하는 게 좋을 수도 있겠다는 생각이 들었는데

보통 팀 프로젝트를 진행하거나
현업에서 업무를 진행할 때는 어떻게 진행되는지가 조금 궁금합니다..!

• 추가적으로 코드 작성하는 부분에서 두드러지는 안좋은 점이나 꼭 고쳤으면 하는 부분이 있으신지가 궁금합니다!
  ( 이 부분은 제 코드가 잘 생각이 안나실 수도 있을 것 같아서 기억이 잘 안나시는 상황이면 패스해주셔도 괜찮을 것 같습니다..!
  너무 많은 코드를 리뷰하고 계실 것 같아서..ㅇㅅㅇ 고생이 많으십니다..! )

• 일단 코드 상에서 크게 안 좋다 싶은 점은 이미 다 코드 리뷰로 드렸었을 거 같아요...! (그런 부분은 웬만하면 지나가지 않고 바로 리뷰를 해드리는 편입니다!) 그거 외에는 거의 모난 부분이 없다고 생각하시면 좋을 거 같아요!
• 간단한 앱 같은 경우에는 유저 플로우를 그리지 않고 시작하기도 합니다. (한 페이지 안에서 끝나는 그런...)
  • 그러나 페이지가 많아지고 하면 그때부터는 유저 플로우를 그리고, 좀 더 나아가서는 유저 시나리오까지도 작성을 하게 됩니다. (유저 시나리오 같은 경우는 인터넷에 레퍼런스가 꽤 있습니다!) 그 부분에서 백엔드 분들과 좀 더 커뮤니케이션 하며 데이터 흐름 같은 것도 더 잡아가면서 기획하실 수 있을 거예요.
  • 또는 와이어 프레임 및 피그마로 UI 같은 것을 구현하면서 이 페이지에서는 대략적으로 이런 데이터가 필요할 것이라고 정의하고 시작하시면 훨씬 더 좋은 기능 구현을 하실 수 있습니다. (이 부분도 백엔드 분들이랑 커뮤니케이션을 하며 자주 수정이 될 수 있는 부분입니다.)
  • 프로젝트 가시면 실무와 거의 비슷하게 기획을 하도록 유도하고, 기능 명세서 같은 것도 작성하게 하므로, 이런 부분들은 프로젝트 가셔서 더 많이 경험하게 되실 겁니다! 👍